[Chapter 10] 10.7 Building Up a Large Site-wide Cache with Forwarders
Author: Cricket Liu & Paul Albitz
Date: 1999-01-06T18:36:26Z

#

| Chapter 10 Advanced Features and Security |

## 10.7 Building Up a Large Site-wide Cache with Forwarders

Certain network connections discourage sending large volumes of traffic off-site, either because the network connection is pay-per-packet or because the network connection is a slow link with a high delay, like a remote office's satellite connection to the company's network. In these situations, you'll want to limit the off-site DNS traffic to the bare minimum. BIND provides a mechanism to do this: forwarders.

If you designate one or more servers at your site as forwarders, all the off-site queries are sent to the forwarders first. The idea is that the forwarders handle all the off-site queries generated at the site, building up a rich cache of information. For any given query in a remote domain, there is a high probability that the forwarder can answer the query from its cache, avoiding the need for the other servers to send packets off-site. Nothing special is done to these servers to make them forwarders; you modify all the other servers at your site to direct their queries through the forwarders.

A primary master or slave name server's mode of operation changes slightly when it is directed to use a forwarder. If the requested information is already in its database of authoritative data and cache data, it answers with this information; this part of the operation hasn't changed. However, if the information is not in its database, the name server will send the query to a forwarder and wait a short period for an answer before resuming normal operation and contacting the remote servers itself. What the name server is doing that's different is sending a recursive query to the forwarder, expecting it to find the answer. At all other times, the name server sends out nonrecursive queries to other name servers and deals with responses that only refer to other name servers.

For example, here is the forwarders conf file statement - and the equivalent BIND 4 boot file directive - for name servers in the movie.edu domain. Both wormhole and terminator are the site forwarders. This forwarders statement is added to every name server conf file except the conf files for the forwarders, wormhole and terminator:

>     options {
>                     forwarders { 192.249.249.1; 192.249.249.3; };
>     };

The equivalent BIND 4 directive is:

>     forwarders 192.249.249.1 192.249.249.3

When you use forwarders, try to keep your site configuration simple. You can end up with configurations that are really twisted.

Avoid having "mid-level" servers forward packets (i.e., avoid having a forwarders line in your mid-level name server's conf file). Mid-level servers mostly refer name servers to subdomain name servers. If they have been configured to forward packets, do they refer to subdomain name servers or do they contact the subdomain name server to find out the answer? Whichever way it works, you're probably making your site configuration too hard for mere mortals (and subdomain administrators) to understand.

> NOTE: Avoid chaining your forwarders. Don't configure server A to forward to server B, and configure server B to forward to server C (or worse yet, back to server A).

10.6 Preferring Name Servers on Certain Networks |  | 10.8 A More Restricted Name Server